home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19941221-19950208
/
000088_news@columbia.edu_Wed Jan 4 14:28:49 1995.msg
< prev
next >
Wrap
Internet Message Format
|
1995-07-31
|
6KB
Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA19211
(5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Wed, 4 Jan 1995 09:28:56 -0500
Received: by apakabar.cc.columbia.edu id AA18959
(5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Wed, 4 Jan 1995 09:28:54 -0500
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.software.testing,comp.protocols.kermit.misc
Subject: Re: testing with kermit
Date: 4 Jan 1995 14:28:49 GMT
Organization: Columbia University
Lines: 129
Message-Id: <3eebb1$igb@apakabar.cc.columbia.edu>
References: <3ec7fo$9ol@mhvnews.kgn.ibm.com>
Nntp-Posting-Host: watsun.cc.columbia.edu
Keywords: kermit testing
Xref: news.columbia.edu comp.software.testing:2980 comp.protocols.kermit.misc:1530
Apparently-To: kermit.misc@watsun.cc.columbia.edu
In article <3ec7fo$9ol@mhvnews.kgn.ibm.com>,
<shapiro@minnie.nic.kingston.ibm.com> wrote:
>To handle repetitive tasks I've resorted to the public domain package
>known as kermit.
>
It's not public domain. Read the copyright notice.
>Even though I'm on a full blown TCPIP network
>with telnet and rsh available everywhere Kermit is convenient
>to "automate" tasks.
>
>Works rather well,
>Commands that complete quickly work great.
>Commands that take a long time, timeout , prematuring terminating the
>process. I've discovered that
>REMOTE SET SERVER TIMEOUT 0
>will make the timeout value infinite, but I still timeout with:
>"Sent too many NAKs"
>
This type of message appears when a file transfer fails. A NAK (Negative
Acknowledgement) occurs when an expected packet does not arrive within the
specified (or default) timeout interval, or when it arrives in damaged
condition (e.g. back checksum).
The only "commands" that time out are file transfers and other protocol-
driven operations (client/server stuff) and script programming commands
that expect certain inputs within a specified or default amount of time.
You can control protocol-related timeouts with the SET { SEND, RECEIVE }
TIMEOUT command. { REMOTE } SET SERVER TIMEOUT controls only one thing:
whether Kermit, when in server mode, sends periodic NAKs while waiting
for commands, i.e. when it is doing nothing. These NAKs are normally not
needed, but if the Kermit program on the other end is not capable of
timing out (e.g. early versions, circa 1981, of CP/M Kermit), then this
would be the only way to break the deadlock that would occur if a
server command packet sent by a non-timing-out client were to be lost
in transit.
>Its especially attrocious when I want to mix a workload of
>quick executing commands and long executing commands.
>All my scripts are short, and are basically single script commands
>with lots of continuation. This is probably why I can't mix.
>
All you have to do is read the manual.
>small sample of a test script:
>
>; SET NETWORK TCP/IP
>LOG SESSION output.out
>SET HOST node
>script gin:--gin:--gin: root word: passwd ]> who ]> date ]> \
>who~sam~si~s& ]> \
>jobs~s~-l ]> \
>who~sam~si ]> quit
>
In this example, you are using the old uucp-style SCRIPT command,
which is not the best way to write scripts because it is cryptic,
limited, and inflexible. There is a much more readable, powerful,
and flexible script programming language that is documented in
chapters 11-13 of the manual (see below). It lets you (for example)
specify an explicit timeout on each item. Your example above might
be recoded as something like this:
LOG SESSION output.out
SET HOST node
SET INPUT ECHO ON ; (or OFF, as you wish)
INPUT 20 gin:
IF FAIL STOP 1 {Failure to get Login prompt}
OUTPUT root\13
INPUT 5 word:
IF FAIL STOP 1 {Failure to get password prompt}
SET INPUT TIMEOUT QUIT
INPUT 30 ]>
OUTPUT who\13
INPUT 10 ]>
OUTPUT date\13
INPUT 10 ]>
OUTPUT who am i\13
INPUT 10 ]>
OUTPUT jobs -l\13
>Anybody got any bright ideas?
>
Read the manual?
Frank da Cruz and Christine M. Gianone, "Using C-Kermit", Digital Press /
Butterworth-Heinemann, Woburn, MA, 1993, 514 pages, ISBN 1-55558-108-0
US single-copy price: $34.95; quantity discounts available. Available in
computer bookstores or directly from Columbia University:
Kermit Development and Distribution
Columbia University Academic Information Systems
612 West 115th Street
New York, NY 10025 USA
Telephone: (USA) 212 854-3703
Domestic and overseas orders accepted. Price: $34.95 (US, Canada, and
Mexico), $45 elsewhere. Orders may be paid by MasterCard or Visa, or
prepaid by check in US dollars. Add $35 bank fee for checks not drawn on
a US bank. Price includes shipping. Do not include sales tax.
Inquire about quantity discounts.
You can also order by phone from the publisher, Digital Press /
Butterworth-Heinemann, with MasterCard, Visa, or American Express:
+1 800 366-2665 (Woburn, Massachusetts office for USA & Canada)
+1 800 665-1148 (Logan Bros, Winnepeg, Manitoba office for Canada)
+44 993 58521 (Rushden, England office for Europe)
+61 2 372-5511 (Chatswood, NSW office for Australia & New Zealand)
+65 220-3684 (Singapore office for Asia)
A German-language edition is also available:
Frank da Cruz and Christine M. Gianone, "C-Kermit - Einfuehrung und
Referenz", Verlag Heinz Heise, Hannover, Germany (1994).
ISBN 3-88229-023-4. Deutsch von Gisbert W. Selke. Price: DM 90,00.
Verlag Heinz Heise GmbH & Co. KG, Helstorfer Strasse 7, D-30625 Hannover.
Tel. +49 (05 11) 53 52-0, Fax. +49 (05 11) 53 53-1 29.
- Frank
P.S. I sympathize with people who don't like the SCRIPT command. Once the
INPUT/OUTPUT/IF/GOTO/FOR/WHILE/etc style of script programming was added to
C-Kermit in version 5A, I was tempted to yank it out, but of course I could
not because many people depended on it. People who want to write new
scripts, however, are encouraged to use the new features rather than the
old SCRIPT command unless they are totally comfortable with the SCRIPT
command and its limitations.